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SUMMARY OF INVENTION 



Generally, the invention concerns scan peripherals. PI, L3; FIG. 1 
(items 12, 16a, 16b). "A scan peripheral is a scanner or multi-function device 
including a scanning function." PI, L7-8. Scan peripherals can be accessed by a 
single machine or by multiple users over a network, for example. PI, L8-12. A scan 
server (FIG. 1, item 10) can assist with controlling access to scan peripherals. "A scan 
peripheral server is typically realized in software that is installed in some type of 
general purpose computer system. Hardware might also be used, but would be more 
difficult to realize. Server software may be run in the general purpose computer of a 
specialized physical device, such as a Hewlett-Packard JetDirect® external or internal 
server. JetDirect® devices can control multiple scan peripherals, including scanners 
and multi-function peripherals." P 1 , L 1 3- 1 8 . 

"Each scan peripheral requires a driver, which functions to control a 
scan job from a particular peripheral according to the capabilities and protocol for 
the particular peripheral" PI 5 LI 8 - P2, LI (emphasis added). "A problem arises 
when a scan peripheral server having a set of drivers or a stand-alone driver 
encounters a scan peripheral unaccounted for by the existing driver(s). This may 
happen, for example, when scan peripherals are replaced with new scan peripherals or 
new scan peripherals are added. In such a case, a new scan peripheral will not work 
with the old server/driver and a user must take additional inconvenient steps to make 
the new scan peripheral work." P2, L4. 

Through the invention, scanning operations may be carried out even 
when the scan peripheral server lacks a driver for the scan peripheral. A driver of the 
invention automatically determines a scan peripheral's capabilities and uses the 
information to configure itself from a set of driver modules. P2, LI 5-20; See, e.g., 
claims 1, 8, and 13; FIG. 2a, Steps 48-54; P6, Lll - 29. In the invention, an 
automatic configuration of a scan driver may take into account user-selected scan 
parameters, and then "[r]eturned parameters allow the driver 18 to configure itself 
based upon those selected parameters and the scan peripheral's capabilities." P6, LI 3- 
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14 (emphasis added); FIGs. 2a -2b. "In FIG. 2b, the driver 18 checks the control 
language 50 and then configures itself according to the control language, for example, 
as a first language configuration 52 or as a second language configuration 54. 
Scanning control languages may be manufacturer specific languages or industry 
shared languages." P6, L21-24. 

ISSUES ON APPEAL 

1) Whether the §102 rejection of claims 1-11 and 13 should be 
reversed as being based on an improper claim interpretation that concludes that scan 
parameters may be interpreted as "pre-stored driving modules" (claim 1 ), a stored "set 
of driver modules" (claim 8), or a "set of scan drive modules" (claim 13) because the 
specification, the claims, and the applied Lo patent all define scan drivers and scan 
parameters separately? 

2) Whether the §102 rejection of claim 12 should be reversed because 
the office action fails to interpret the claimed "capability descriptor" consistently with 
the specification and fails to adequately identify the particular feature of Lo alleged to 
correspond to the "capability descriptor" stored in the memory of the claim 12 
peripheral? 

3) Whether the §103 rejection of claim 6 should be reversed as being 
based upon an incorrect understanding of the art, and whether the rejection of claims 
7-9 should be reversed because the examiner has failed to set forth a prima facie case 
and the evidence of record does not support the conclusion of obviousness? 

GROUPING OF CLAIMS 

To conduct this appeal economically and for the limited purposes of this 
appeal, dependent claims 2-7 stand or fall with associated independent claim 1; and 
dependent claims 9-1 1 stand or fall with associated independent claim 8. 
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ARGUMENT 



I. The §102 Rejection of the Claims 1-11 and 13 In View of Lo is Based Upon 
an Unreasonable Determination that Lo's Scan Parameters are the Same 
as "Pre-Stored Driving Modules" (claim 1), a Stored "Set of Driver 
Modules" (Claim 8), or a "Set of Scan Drive Modules" (claim 13) Because 
the Interpretation Ignores the Different Meaning Given in the Art and the 
Record to Scan Parameters and Scan Drivers. 

Claims 1-11 and 13 stand rejected under §102 in view of Lo. This 
rejection should be reversed as it is based upon an improper interpretation of the 
claims, and a misinterpretation of Lo. The present claims, the specification, the art, 
and Lo all give different, clear meaning to scan drivers that is different than scan 
parameters, and the Examiner's reading of Lo's scan parameters upon the claimed 
scan drive modules is accordingly unreasonable. 

"A claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631 (Fed. 
Cir. 1987). "The ordinary and customary meaning of a claim term to one of ordinary 
skill in the art may be ascertained from a variety of sources, first, as Vitronics 
instructs, from the intrinsic evidence of record such as the claims themselves, the 
written description, and the prosecution history, but also from the 'common 
understanding' of the terms that may be reflected in dictionaries, encyclopedias, and 
treatises." W.E. Hall Co., Inc. v. Atlanta Corrugating, LLC, 370 F.3d 1343, 1350(Fed. 
Cir. 2004) (citation omitted). Claim terms are presumed to have the ordinary and 
customary meanings attributed to them by those of ordinary skill in the art. Sunrace 
Roots Enter. Co. v. SRAM Corp., 336 F.3d 1298, 1302 (Fed. Cir. 2003). The broadest 
reasonable interpretation of the claims to be given during examination by the USPTO 
must be consistent with the interpretation that those skilled in the art would reach. In 
re Cortright, 165 F.3d 1353 (Fed. Cir. 1999). 
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The use of different claim terms gives rise to an inference that separate 
meaning is intended by the different terms. Bancorp Services, L.L.C. v. Hartford Life 
Ins. Co., 359 F.3d 1367, 1373(Fed. Cir. 2004). Claim terms must be given the 
definition indicated in the specification and the claim. Vitronics Corp. v. 
Conceptronic, Inc., 90 F.3d 1576, 1585(Fed. Cir. 1996). "Prior art references may 
also be more indicative of what all those skilled in the art generally believe a certain 
term means" than extrinsic evidence. Id. at 1584. 

The office actions have ignored the ordinary meaning given scan drivers 
and scan parameters in the art, used in the present specification, and even in the Lo 
reference. Most recently, in the advisory action, the position is explained with 
reference to a general dictionary definition of "modules" (advisory action at p. 3). 
The advisory action also discussed "pre-stored printer drivers", which have never been 
mentioned during prosecution. What the office action fails to account for is the clear 
intrinsic evidence that indicates that the broadest reasonable interpretation of a scan 
drivers as being different from scan parameters. Drivers are given clear meaning in 
the specification, claims, and Lo, and parameters are indicated in all three sources as 
having a separate meaning. 

a. The Present Specification Sets forth the Ordinary Meaning for "Pre- 
Stored Driving Modules" (Claim 1), a Stored "Set of Driver Modules" 
(Claim 8), or a "Set of Scan Drive Modules" (Claim 13), and that 
Ordinary Meaning is Ignored in the Rejection. 

The specification is one of the many intrinsic sources in the present 
record that establish that the rejection fails to accord ordinary meaning to the claimed 
scan driver modules by comparing them to Lo's scan parameters. This is the 
predication for the rejection, and if the interpretation is incorrect then the rejection has 
failed to establish a §102 rejection. A first source for understanding the claim terms is 
the present specification. 

According to the present specification, a driver "functions to control a 
scan job from a particular peripheral according to the capabilities and protocol for the 
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particular peripheral." PI, LI 8 - P2, LI. In the invention, an automatic configuration 
of a scan driver may take into account user-selected scan parameters, and then 
"[r]eturned parameters allow the driver 18 to configure itself based upon those 
selected parameters and the scan peripheral's capabilities." P6, LI 3-14 (emphasis 
added); FIGs. 2a -2b. "In FIG. 2b 5 the driver 18 checks the control language 50 and 
then configures itself according to the control language, for example, as a first 
language configuration 52 or as a second language configuration 54. Scanning control 
languages may be manufacturer specific languages or industry shared languages." P6 5 
L21-24. FIG. 2b illustrates a scan driver configuring itself with the appropriate driver 
modules according to the peripheral capabilities and user set scan parameters. P6, 
LI 3-20. "Using the configured driver modules, the scan is then executed 72." P6, 
L28-29. 

Scan parameters are options selected by a user. P6, L6-13. Drivers, on 
the other hand, function "to control a scan job from a particular peripheral according 
to the capabilities and protocol for the particular peripheral." In the claims, a driver is 
configured from driver modules. Thus, a driver of the invention uses scanner 
capability information and scan parameters to "configure itself from a set of driver 
modules." 

b. The Lo Reference Itself Uses the Same Ordinary Meaning Accorded 

Scan "Drivers" and Driver Modules, and Further Establishes as 

Distinct Ordinary Meaning for "Scan Parameters". 

Another source to indicate that the office action's interpretation of scan 
parameters as reading on the "pre-stored driving modules" (claim 1), a stored "set of 
driver modules" (claim 8), or a "set of scan drive modules" (claim 13) is the Lo 
reference itself. Lo gives clear different meaning to scan drivers and scan parameters. 
According to Lo, scanner parameters are options such as the "resolution, brightness, 
and contrast". CI 5, L45-46. In contrast, a scan driver is "software which controls the 
image device" and is "analogous to a print driver". C5, L37-40. Scan options or 
parameters are not the same as a scan driver, as clearly indicated by Lo. In Lo, the 
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scan driver is the "source device driver" that is "usually written by the manufacturer 
of the scanner". C5, L32-41. Lo, like any other ordinary artisan, recognizes the 
difference between scan parameters and scan drivers. "The source device driver 42 
includes a source user interface 44 which allows control of the scanner 50 including 
the control of the parameters of the scanner 50." C5, L34-36. 

c. The Different Use of Driver Modules and Scan Parameters in the 
Claims, Further Shows that the Interpretation of Lo's Scan Parameters 
as Corresponding to the Disputed Claim Terms is Unreasonable, . 

The claims themselves are a third source to show that ordinary meaning 
of drivers and parameters indicates that the rejection is based upon an unreasonable 
interpretation. "[T]he use of [different claim] terms in close proximity in the same 
claim gives rise to an inference that a different meaning should be assigned to each." 
Bancorp Services, L.L.C. v. Hartford Life Ins. Co. 359 F.3d at 1373. This inference is 
not valid only where it is apparent that the terms were intended mean the same thing, 
such as when poor drafting uses different terms for the same element. Id. 

In claim 1 , a scan driver is configured from "a set of pre-stored driving 
modules being selected according to user set parameters in the scan job and 
capabilities". Parameters are clearly given different meaning in claim 1 from the pre- 
stored driving modules that are selected for form a scan driver. The specification, as 
indicated above, also is consistent. Nowhere does the present application of the art 
give the same meaning for scan "parameters" and scan "drivers" or "driving 
modules". The claim 1 phrase would be indefinite if "parameter" and "driving 
modules" had the same meaning. 

In claim 8, similarly, the step of "accepting parameters for a scan job" is 
used. The claim also includes the steps of "linking driver modules". From this, it is 
improper to interpret scan parameters (options for a scan job) as the same as scan 
drivers (which are necessary to control the operations of a scan device). 
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d. When the Claim Terms are Given Their Ordinary Meaning as 
Established by the Specification, by Lo, and by the Claim Language 
Itself, It is Clear That Lo Fails to Disclose the Invention of Any of 
Claims 1, 11, or 13. 

Nothing in Lo describes linking a set of pre-stored driving modules as 
required by claim 1, linking driver modules from a set of driver modules and 
controlling a scan job according to the driver modules as required by claim 8, or 
configuring the scan driver module from a set of scan driver modules as required by 
claim 13. This is explicitly contradicted by Lo, in fact, because Lo describes the very 
same conventional process that is overcome by the presently claimed invention. In 
column 5, beginning at line 31, Lo explicitly describes that the scan peripherals in the 
system of Lo require a "software or source device driver 42" which "is software which 
controls the image acquisition device and is written by the device developer to comply 
with TWAIN specifications". Lo goes on to explain that "the source device driver 42 
is usually written by the manufacturer of the scanner 50. The source device driver 42 
may be installed in a manner which analogous to installing a print driver in a 
Windows based computer." Nothing in any of the embodiments of Lo discloses 
constructing a scan driver according to capability descriptors and pre-stored driving 
modules as is required in varying scope by each of independent claims 1, 8 and 13. 
Lo assumes that a driver for the scanner is available from the manufacturer and never 
discusses creating a scan driver based upon driver modules. Instead, what Lo 
discloses is a system and methods that permit a client computer to communicate over 
a network to control a scanner, but in each case it is assumed that the driver that is 
provided by the manufacturer is available to control the scan operation. 

The examiner has viewed the TWAIN interface as a scan driver 
(Advisory Action P. 3, Final Office action P. 4), but the above-cited portion of column 
5 and the remaining portions of the Lo patent contradicts such an interpretation. 
TWAIN and the packet structure, such as those shown in Figs. 7A-7L, require a pre- 
written manufacturer's driver 42. There is a method disclosed for communication 
packets that allows the creation of a scan job from a client computer, but the creation 
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of a scan job by a client is not the same as the configuring of a driver module as is 
claimed. Each of the portions of Lo cited by the examiner relates to communication 
packets for creating a scan job and assumes that the device driver 42 that is pre- 
written by the manufacturer is available for the scanner that would be accessed by the 
scan job. 

The examiner cited column 12, lines 7-50 and column 15, line 34 
through column 16, line 64 and step 468 in Fig. 8B in the first office action as meeting 
the applicable claim limitations. The portion of column 12 only discusses the 
communication of scanner settings to a client so that the client may select "the ranges 
and possible settings of the scanner" for a particular scan job. There is no discussion 
of configuring a set of modules based upon this information, and the figure mainly 
concerns the TWAIN style packet that will be used for the communication of the 
information to the client. The portion in columns 15 and 16 discusses the display of 
the scanner settings at the client computer 102. This again allows the client to choose 
settings so that a scan job may be conducted, but there is no disclosure of forming a 
driver from a set of modules, as again Lo relies upon the driver 42 provided by the 
manufacturer. The likening of the TWAIN driver to the scan driver contradicts Lo's 
disclosure of a device driver 42 and the definition of TWAIN as a "standard software 
protocol and API (application programming interface) for communication between 
software applications and image acquisition devices (the source of the image data)." 
In sum, there is no support anywhere in Lo for anything other than a "source device 
driver 42" that "may be installed in a manner which is analogous to installing a print 
driver in a windows-based computer." This is the exact problem solved by the 
invention, which overcomes the problems encountered when a scan server "a set of 
drivers or a stand-alone driver encounters a scan peripheral unaccounted for by the 
existing driver(s)." P2, L4-5. 



II. The Rejection of Claim 12 Fails to Recognize the Clear Meaning Given 
Capability Descriptor in the Claims and the Specification. 

In the advisory action, the rejection of claim 12 is defended on the basis 
that the term is unduly broad. Advisory Action P. 4 ("as the claim is currently 
worded, one of ordinary skill in the art can interpret the peripheral as the scanner 
server 130"). This explanation, however, fails to account for the meaning of the 
claim. 

Claim 12 specifies a peripheral that stores in its memory a scan 
capability descriptor and communicates the capability descriptor in response to a 
query requesting the same. No such scan device is disclosed in Lo. The scanners 50 
or 144 utilized in Lo are conventional scanners. The examiner points to portions of 
column 8 and column 9 as disclosing a peripheral including a scanning capability that 
stores a scan capability descriptor in its memory. Nothing in this portion of Lo 
discloses that the scan device 50 or 144 stores a capability descriptor or responds to 
queries regarding the same. Instead, the portion cited by the examiner discusses 
storing of information by the scanner server computer 130, and not the scan device 
144 shown in the same figures. The scanner server computer 130 creates a scanner 
image table 160 shown in Fig. 5 and other information that permits a client to execute 
a scan job over the network. Nowhere is there any discussion of the scanner 144 or 
the scanner 50 discussed earlier in the specification of storing a capability descriptor. 
As discussed in the instant specification, when a scanner provides a capability 
descriptor it facilitates the automatic creation of a scan driver as is enabled by certain 
embodiments of the invention. See, FIG. 2a, step 24, e.g., and P5, L3-13. 
"Information contained in the capability descriptor provides the basis for identifying 
the exact nature of scanning supported by a scan peripheral with which the capability 
descriptor is associated." P4, L21-25. Whether or not the peripheral is the server as 
suggested by the examiner, Lo still lacks a capability descriptor. A "capability 
descriptor provides information about the scan capabilities offered by the peripheral 
and is preferably realized as a data string." P4, L21-25. 
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CONCLUSION 



For the above reasons, Applicant requests the Board to reverse 
the outstanding rejections. The case should then be permitted to pass to allowance. 

Respectfully submitted, 



GREER, BURNS & CRAIN, LTD. 




Attorney for Applicant 

June 10, 2005 

300 S. Wacker Drive - Suite 2500 
Chicago, Illinois 60606-6501 
Telephone: (312)360-0080 
Facsimile: (312)360-9315 
Customer No. 24978 
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CLAIMS: 



1 . A program for interfacing a client computer to one or more scan 

peripheral devices, the program comprising functions for: 

querying a scan peripheral for a capability descriptor; 

determining whether an appropriate capability descriptor is 
obtained in response to said step of querying; 

storing a capability descriptor associated with a scan peripheral 
for which an appropriate information capability descriptor has been received as 
determined in said step of determining; 

configuring a scan driver for a scan job for a scan peripheral 
when a scan job is requested by a client by linking a set of pre-stored driving 
modules, a set of pre-stored driving modules being selected according to user 
set parameters in the scan job and capabilities indicated in a stored information 
capability descriptor concerning a scan peripheral to which the scan job is 
directed. 

2. The program according to claim 1, further comprising a step 
of de-linking pre-stored driving modules upon completion of a scan job. 

3. The program according to claim 1, wherein said step of 
configuring includes extracting information from a stored capability descriptor 
to alter a user interface dependent upon a peripheral's capabilities. 

4. The program according to claim 1, wherein a capability 
descriptor stored in said step of storing comprises a string including fields 
indicating dots per inch capabilities, paper size capabilities, color/grayscale 
options, image formats supported, and whether or not a preview scan is 
supported. 

5. The program according to claim 1, stored in a server which 
provides an interface to a network and at least one scan peripheral. 
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6. The program according to claim 1, stored in a computer 
connected to at least one scan peripheral. 

7. The program according to claim 1, further comprising a 

functions for: 

obtaining a model of scan peripheral for a peripheral when said 
function for determining determines that an appropriate capability descriptor 
was not received in response to a query conducted by said function for 
querying; and 

associating a pre-stored capability descriptor with a scan 
peripheral whose model was determined by said step of obtaining. 

8. A scan peripheral server having a network connection 
interface and one or more ports for connection to at least one scan peripheral, 
the server including: 

memory for storing capability descriptors defining capabilities of 
scan peripherals; 

memory for storing a set of driver modules; and 
a program for controlling execution of scan jobs requested from 
the network connection of a scan peripheral connected to one of said one or 
more ports, the program comprising functions for 

obtaining a capability descriptor from one or more scan 
peripherals connected to any of said one or more ports; 

storing a received capability descriptor in said memory for 
storing capability descriptors; 

accepting a scan job request from said network connection 
for one or more scan peripherals attached to said one or more ports; 

extracting capability information from a stored capability 
descriptor in response to a scan job; 
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sending information to said network connection to modify 

a user interface; 

accepting parameters for a scan job from said network 

connection; 

linking driver modules from said set of driver modules 
according to capability information extracted by said function for extracting 
and parameters accepted by said function for accepting; and 

controlling a scan job according to the driver modules 
linked in said function for linking. 

9. The server according to claim 8, wherein a capability 
descriptor comprises a data string of capability data. 

10. The server according to claim 8, wherein said program for 
controlling execution of scan jobs further comprises: 

obtaining model information from any one or more scan 
peripherals connected to any of said one or more ports when said any one or 
more scan peripherals does not provide a capability descriptor; and 

associating a capability descriptor pre-stored in said memory for 
storing capability descriptors with said any one or more scan peripherals which 
does not provide a capability descriptor according to model information 
obtained in said step of obtaining. 

11. The server according to claim 8, wherein a data string is 
formatted as a data string including a scan language, an image format, a 
resolution and a preview scan capability. 

12. A peripheral including a scanning capability, the peripheral 

comprising: 

a scan system for scanning documents and producing electronic 
data therefrom; 
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an interface for connecting to a client machine or server; 
memory for storing data; 

a scan capability descriptor stored in said memory; and 
a controller for communicating with said client machine or server 
through said interface to perform a scan job, said controller sending said 
capability descriptor to said client machine or server through said interface in 
response to a query requesting a capability descriptor. 

13. A method for controlling a scan job directed to a 
peripheral including a scanning function, the method comprising steps of: 

obtaining a capability descriptor from the peripheral including the 
scanning function; then, to implement a scan job, 

configuring a scan driver from a set of scan drive modules based 
upon capabilities indicated by said capability descriptor and parameters 
included in the scan job. 
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